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Sir: 



The examiner has finally rejected claims 1-23, 26, and 27 under 35 U.S.C. §102(e) as being 
anticipated by Sarkkinen (U.S. Patent Pub. No. 2005/0015583). The assignee hereby requests 
reviev^ of the final rejection prior to filing an appeal brief for the reasons set forth below because the 

final rejection fails to make a prima facie case of unpatentability and there is clear error in the 
rejections of these claims. Any fees due should be charged to Jones Day Deposit Account No. 
501432, ref: 555255-012562. 



Claim 1 - The cited Sarkkinen reference fails to teach sending from the user device the generated 
broadcast key over a network, wherein the generated broadcast key indicates that multicast 
content is to be provided to the user device. 

Claim 1 recites: 

1. (Original) A multicast content accessing method for use on a user device, 
wherein a multicast service provides the multicast content, comprising: 

receiving multicast service activation data over a network; 

generating on the user device a broadcast key; 

sending from the user device the generated broadcast key over a network; 
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wherein the generated broadcast key indicates that multicast content is to be 
provided to the user device. 

In rejecting claim 1, the office action maintains that Sarkkinen discloses the features of claim 
1. For example, the office action maintains that paragraphs 22-26 of Sarkkinen disclose that a 
broadcast key is generated on the user device and that the generated broadcast key is sent from the 
user device over a network as recited in claim 1 . 

The processing of claim 1 includes: 



Provided 

The arrows in the processing flow indicate what is being received and sent from a user device. 

Sarkkinen does not disclose such processing. In rejecting claim 1, the office action cites to 
FIG. 7 as disclosing the multicast content accessing method of claim 1 . The Sarkkinen process of 
FIG. 7 is summarized below as described in paragraphs [0291]- [0295]: 



User Device 



Receive Multicast 
Service Activation 



Generate a 
Broadcast Key 



Send the Generated 

Broadcast Key 
Indicating Multicast 
Content Is to Be 
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User Entity 

I 

S1 2 Receive Part of ^ 

Ciphering Information 

S1 3 SendlVlBiVIS Joining ^ 

Request IVlessage 

S15 Receive Remainder of Cipliering 
Information in MBMS Joining Response"^ 
Message 

S16 Generate Cipliering 
Key 

S1 8 MBMS Data Transmission 
Received and Decrypted 
Using Ciphering Key 

It is clear that none of the cited portions of Sarkkinen teach the step of sending from the user 
device the generated broadcast key over a network, where the generated broadcast key indicates that 
multicast content is to be provided to the user device. FIG. 7 of Sarkkinen shows part of the 
ciphering information being sent to the UE upon service registration/subscription and the remainder 
of the ciphering information being sent to the UE foHowing a join request. The ciphering key is then 
generated at S16 and used to decrypt the data transmission at SI 8. The ciphering key in Sarkkinen is 
not sent from the user entity. This is because the ciphering key of Sarkkinen is used as a key to 
decrypt a received data stream. In contrast, the key of claim 1 is sent from the user device because 
the claim 1 broadcast key is used to indicate that multicast content is to be provided to the user 
device. The Sarkkinen key is very different in form and function, and, therefore, it does not meet the 
limitations associated with the key in claim 1. 
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Following submission of the above arguments in an after final response, an advisory action 

was received on April 15, 2009. The advisory action states: 

In response to applicant's argument that Sarkkinen does not disclose "sending from 
the user device the generated broadcast key over a network. . ." Examiner respectfully 
disagrees. Sarkkinen discloses the broadcast/multicast key is decrypted at the user 
entity (user device), however, the input parameters for ciphering the broadcast key is 
sent to the user device at the time of registration (para #0028) and stored at the user 
device (para #0032). Generating a multicast/broadcast key requires ciphering key 
which is stored in the user device to decrypt the multicast/broadcast key. Therefore, 
Sarkkinen discloses generating on the user device the broadcast key. 

It is respectfully submitted that the discussion provided in the advisory action is not on point with 
the argument made by assignee in the after final response. Assignee has not argued that Sarkkinen 
does not disclose the generating the broadcast key on the user device limitation. In fact, the 
illustration appearing on page 3 of this pre-appeal brief depicts the Sarkkinen user entity generating 
a key at SI 6. The claim limitations that assignee has argued are not taught in Sarkkinen are the last 
two limitations: 

sending from the user device the generated broadcast key over a network; 
wherein the generated broadcast key indicates that muhicast content is to be 
provided to the user device. 

None of the cited portions of Sarkkinen teach the sending of a generated broadcast kev from the 

user device over a network, let alone sending a key that indicates multicast content is to be provided 

to the user. This is clearly shown in the illustration on page 3 of this brief, which shows the only 

transfer from the user entity is the MBMS joining request at SI 3. The transfer at S13 could not 

possibly include the key because the key is not even generated until SI 6. The only transfer of data 

discussed in the advisory action comments is a transfer of input parameters for ciphering the 

broadcast key to the user entity. There is no teaching of sending a broadcast key from the user 

device as required by claim 1 . 
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This difference between Sarkkinen and the claims at issue is logical because the two keys are 
completely different in function and purpose. The Sarkkinen key is used to decrypt received data at 
the user entity. In contrast, the key of claim 1 is sent from the user device to indicate that content is 
to be provided to the user device. Because the Sarkkinen key is for a very different purpose than the 
key of claim 1, it is natural that Sarkkinen does not teach the claimed limitations. Because 
Sarkkinen does not teach at least the above described limitations, it is requested that the § 102 
rejection of claim 1 be withdrawn. 

Independent claim 26 contains the limitation of the generated broadcast key indicating that 
content is to provided to the user device, and independent claim 27 includes a similar limitation plus 
means for sending from the user device the generated broadcast key over a network. Because 
Sarkkinen does not teach these claimed limitations, it is respectfully requested that the § 102 
rejections of claims 26 and 27 be withdrawn for similar reasoning as offered for claim 1 . 

For at least the above reasons, the assignee submits that the rejection of claims 1 , 26, and 27 
are clearly in error and must be withdrawn. The Panel is therefore respectfully requested to 
withdraw the rejections of claims 1-23, 26, and 27 and to pass this case to issue. 



Joseph Nf. Sauer (Reg. No. 47,919) 
Jones Day 

North Point, 901 Lakeside Avenue 
Cleveland, OH 44114 
(216)586-7516 



Respectfully si/bmitted, 



JONES DAY, 



By: 
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